Though information technology (IT) transformation programs are gaining in importance, we know little about the nature of the challenges involved in such programs and how to manage them. Using grounded theory methodology, we conducted a multiyear case study of a large IT transformation program in a major commercial bank, during which we encountered the interrelated themes of paradoxes and ambidexterity. Grounded in our case, we construct a substantive theory of ambidexterity in IT transformation programs that identifies and explains the paradoxes that managers need to resolve in IT transformation programs. The ambidexterity areas we identified are (1) IT portfolio decisions (i.e., IT efficiency versus IT innovation), (2) IT platform design (i.e., IT standardization versus IT differentiation), (3) IT architecture change (i.e., IT integration versus IT replacement), (4) IT program planning (i.e., IT program agility versus IT project stability), (5) IT program governance (i.e., IT program control versus IT project autonomy), and (6) IT program delivery (i.e., IT program coordination versus IT project isolation). What weaves these six areas together is the combined need for IT managers to employ ambidextrous resolution strategies to ensure short-term IT contributions and continuous progress of IT projects while simultaneously working toward IT transformation program success as a foundation for IT-enabled business transformation. However, in addition to this commonality, we find that the nature of paradoxical tensions differs across the six areas and requires slightly different management strategies for paradox resolution. Ambidexterity areas (1), (2), and (3) are associated with IT transformation strategizing and, in addition to balancing short- and long-term goals, require the mutual accommodation and blending of business and IT interests in the spirit of IT-business partnering to achieve IT-enabled business change and IT-based competitiveness. Ambidexterity areas (4), (5), and (6) are associated with IT program and project execution and, in addition to balancing short- and long-term requirements, require a recurrent and dynamic act of balancing ÒlocalÓ needs at the IT project level and ÒglobalÓ needs at the IT program level.
While much is known about selecting different types of control that can be exercised in information systems development projects, the control dynamics associated with ISD offshoring projects represent an important gap in our understanding. In this paper, we develop a substantive grounded theory of control balancing that addresses this theoretical gap. Based on a longitudinal case study of an ISD offshoring project in the financial services industry, we introduce a three-dimensional control configuration category that emerged from our data, suggesting that control type is only one dimension on which control configuration decisions need to be made. The other two dimensions that we identified are control degree (tight versus relaxed) and control style (unilateral versus bilateral). Furthermore, we illustrate that control execution during the life cycle of an ISD offshoring project is highly intertwined with the development of client-vendor shared understanding and that each influences the other. Based on these findings, we develop an integrative process model that explains how offshoring project managers make adjustments to the control configuration periodically to allow the ISD offshoring project and relationship to progress, yielding the iterative use of different three-dimensional control configurations that we conceptualize in the paper. Our process model of control balancing may trigger new ways of looking at control phenomena in temporary interfirm organizations such as client-vendor ISD offshoring projects. Implications for research on organizational control and ISD offshoring are discussed. In addition, guidelines for ISD offshoring practitioners are presented.
Software project escalation is a costly problem that leads to significant financial losses. Prior research suggests that setting a publicly announced limit on resources can make individuals less willing to escalate their commitment to a failing course of action. However, the relationship between initial budget and schedule goals and software project escalation remains unexplored. Drawing on goal setting theory as well as sunk cost and mental budgeting perspectives, we explore the effect of goal difficulty and goal specificity on software project escalation. The findings from a laboratory experiment with 349 information technology professionals suggest that both very difficult and very specific goals for budget and schedule can limit software project escalation. Further, the level of commitment to a budget and schedule goal directly affects software project escalation and also interacts with goal difficulty and goal specificity to affect software project escalation. This study makes a theoretical contribution to the existing body of knowledge on software project management by establishing a connection between goal setting theory and software project escalation. The study also contributes to practice by highlighting the potential negative consequences that can result from the nature of initial budget and schedule goals that are established at the outset of a project.
We examined 335 business process outsourcing (BPO) ventures to understand the effect of contractual and relational governance factors on BPO satisfaction from the client's perspective. While both contractual and relational factors explain significant variance in BPO satisfaction, relational factors dominate. By examining interactions between key contractual and relational mechanisms, we found that elements of the two governance approaches operate as substitutes with respect to BPO satisfaction. Specifically, the relational mechanism, trust, was found to substitute for contractually specified activity expectations, goal expectations, and contractual flexibility. Similarly, the relational mechanism, information exchange, was found to substitute for contractually specified activity expectations and goal expectations. Finally, the relational mechanism, conflict resolution, was found to substitute for contractually specified goal expectations. Our results can be applied to more effectively realize controls in outsourcing contexts and to design governance systems that integrate contractual and relational governance mechanisms based on the characteristics of client-vendor relationships.
Digital inequality, or unequal access to and use of information and communication technologies (ICT), is a severe problem preventing the socioeconomically disadvantaged (SED) from participating in a digital society. To understand the critical resources that contribute to digital inequality and inform public policy for stimulating initial and continued ICT usage by the SED, we drew on capital theories and conducted a field study to investigate: (1) the forms of capital for using ICT and how they differ across potential adopters who are SED and socioeconomically advantaged (SEA); (2) how these forms of capitals are relatively impacted for the SEA and the SED through public policy for ICT access; and (3) how each form of capital influences the SED's intentions to use initially and to continue to use ICT. The context for our study involved a city in the southeastern United States that offered its citizens free ICT access for Internet connectivity. Our results show that SED potential adopters exhibited lower cultural capital but higher social capital relative to the SEA. Moreover, the SED who participated in the city's initiative realized greater positive gains in cultural capital, social capital, and habitus than the SEA. In addition, we find that the SED's initial intention to use ICT was influenced by intrinsic motivation for habitus, self-efficacy for cultural capital, and important referents' expectations and support from acquaintances for social capital. Cultural capital and social cultural capital also complemented each other in driving the SED's initial use intention. The SED's continued use intention was affected by both intrinsic and extrinsic motivations for habitus and both knowledge and self-efficacy for cultural capital but was not affected by social capital. We also make several recommendations for future research on digital inequality and ICT acceptance to extend and apply the proposed capital framework.
Although the choice of control mechanisms in systems development projects has been extensively studied in prior research, differences in such choices across internal and outsourced projects and their effects on systems development performance have not received much attention. This study attempts to address this gap using data on 57 outsourced and 79 internal projects in 136 organizations. Our results reveal a paradoxical overarching pattern: controllers attempt greater use of control mechanisms in outsourced projects relative to internal projects, yet controls enhance systems development performance in internal projects but not in outsourced projects. We introduce a distinction between attempted control and realized control to explain this disconnect, and show how anticipated transaction hazards motivate the former but meeting specific informational and social prerequisites facilitate the latter. Our results contribute three new insights to the systems development control literature. First, controllers attempt to use controller-driven control mechanisms to a greater degree in outsourced projects but controllee-driven control mechanisms to a greater degree in internal projects. Second, we establish a hitherto-missing control--performance link. The nuanced differences in internal and outsourced projects simultaneously confirm and refute a pervasive assertion in the information systems controls literature that control enhances performance. Finally, we show how requirements volatility--which can be at odds with control--alters the control--performance relationships. Implications for theory and practice are also discussed.
Digital inequality is one of the most critical issues in the knowledge economy. The private and public sectors have devoted tremendous resources to address such inequality, yet the results are inconclusive. Theoretically grounded empirical research is needed both to expand our understanding of digital inequality and to inform effective policy making and intervention. The context of our investigation is a city government project, known as the LaGrange Internet TV initiative, which allowed all city residents to access the Internet via their cable televisions at no additional cost. We examine the residents' post-implementation continued use intentions through a decomposed theory of planned behavior perspective, which is elaborated to include personal network exposure. Differences in the behavioral models between socio-economically advantaged and disadvantaged users who have direct usage experience are theorized and empirically tested. The results reveal distinct behavioral models and isolate the key factors that differentially impact the two groups. The advantaged group has a higher tendency to respond to personal network exposure. Enjoyment and confidence in using information and communication technologies, availability, and perceived behavioral control are more powerful in shaping continued ICT use intention for the disadvantaged. Implications for research and practice are discussed.
Advocates of software risk management claim that by identifying and analyzing threats to success (i.e., risks) action can be taken to reduce the chance of failure of a project. The first step in the risk management process is to identify the risk itself, so that appropriate countermeasures can be taken. One problem in this task, however, is that no validated lists are available to help the project manager understand the nature and types of risks typically faced in a software project. This paper represents a first step toward alleviating this problem by developing an authoritative list of common risk factors. We deploy a rigorous data collection method called a "ranking-type" Delphi survey to produce a rank-order list of risk factors. This data collection method is designed to elicit and organize opinions of a panel of experts through iterative, controlled feedback. Three simultaneous surveys were conducted in three different settings: Hong Kong, Finland, and the United States. This was done to broaden our view of the types of risks, rather than relying on the view of a single culture--an aspect that has been ignored in past risk management research. In forming the three panels, we recruited experienced project managers in each country. The paper presents the obtained risk factor list, compares it with other published risk factor lists for completeness and variation, and analyzes common features and differences in risk factor rankings in the three countries. We conclude by discussing implications of our findings for both research and improving risk management practice.
The problem of "runaway" information systems (IS) projects can be exacerbated by the reluctance of organizational members to transmit negative information concerning a project and its status. Drawing upon relevant bodies of literature, this paper presents a model of the reluctance to report negative project news and develops hypotheses to be tested. An experiment, which was designed to test these hypotheses for both internal and external reporting alternatives, is then described. Two factors are manipulated: (1) the level of impact associated with project failure should an individual fail to report negative information, and (2) the level of observed behavioral wrongdoing associated with the project. The results explain a significant portion of the variance in the reluctance to report negative information and suggest that some differences in internal and external reporting behavior. Implications for research and practice are discussed.
One of the most challenging decisions that a manager must confront is whether to continue or abandon a troubled project. Published studies suggest that failing software projects are often allowed to continue for too long before appropriate management action is taken to discontinue or redirect the efforts. The level of sunk cost associated with such projects has been offered as one explanation for this escalation of commitment behavior. What prior studies fail to consider is how concepts from risk-taking theory (such as risk propensity and risk perception) affect decision makers' willingness to continue a project under conditions of sunk cost. To better understand factors that may cause decision makers to continue such projects, this study examines the level of sunk cost together with the risk propensity and risk perception of decision makers. These factors are assessed for cross-cultural robustness using matching laboratory experiments carried out in three cultures (Finland, the Netherlands, and Singapore). With a wider set of explanatory factors than prior studies, we could account for a higher amount of variance in decision makers' willingness to continue a project. The level of sunk cost and the risk perception of decision makers contributed significantly to their willingness to continue a project. Moreover, the risk propensity of decision makers was inversely related to risk perception. This inverse relationship was significantly stronger in Singapore (a low uncertainty avoidance culture) than in Finland and the Netherlands (high uncertainty avoidance cultures). These results reveal that some factors behind decision makers' willingness to continue a project are consistent across cultures while others may be culture-sensitive. Implications of these results for further research and practice are discussed.
Project failure in the information technology area is a costly problem, and troubled projects are not uncommon. In many cases, these projects seem to take on a life of their own, continuing to absorb valuable resources, while failing to deliver any real business value. While prior research has shown that managers can easily become locked into a cycle of escalating commitment to a failing course of action, there has been comparatively little research on de-escalation, or the process of breaking such a cycle. Through de-escalation, troubled projects may be successfully turned around or sensibly abandoned. This study seeks to understand the process of de-escalation and to establish a model for turning around troubled projects that has both theoretical and practical significance. Through a longitudinal case study of the IT-based baggage handling system at Denver International Airport (DIA), we gathered qualitative data on the de-escalation of commitment to a failing course of action, allowing us to inductively develop a model of the de-escalation process as it unfolded at DIA. The model reveals deescalation as a four-phase process: (1) problem recognition, (2) re-examination of prior course of action, (3) search for alternative course of action, and (4) implementing an exit strategy. For each phase of the model, we identified key activities that may enable de-escalation to move forward. Implications of this model for both research and practice are discussed.
Software projects can often spiral out of control to become ‘runaway systems’ that far exceed original budget and schedule projections. The behavior that underlies many runaway systems can best be characterized as ‘escalation of commitment to a failing course of action.’ The objectives of this study were to: (1) understand the extent to which IS projects are prone to escalate, (2) compare the outcomes of projects that escalate with those that do not, and (3) test whether constructs associated with different theories of escalation can be used to discriminate between projects that escalate and those that do not A survey was administered to IS audit and control professionals and, to establish a baseline for comparison, the survey was designed to gather data on projects that did not escalate as well as those that did escalate. The results of our research suggest that between 30% and 40% of all IS projects exhibit some degree of escalation. Projects that escalated had project outcomes that were significantly worse in terms of perceived implementation performance and perceived budget/schedule performance, as compared to projects that did not escalate. Using constructs from theories that have been used to explain the escalation phenomenon, we were able to test various logistic regression models for their ability to discriminate between projects that escalate and those that do not. To construct our models, we explored constructs derived from self-justification theory, prospect theory, agency theory, and approach avoidance theory. While constructs derived from all four theories were significant in logistic regression models, the completion effect construct derived from approach avoidance theory provided the best classification of projects, correctly classifying over 70% of both escalated and non-escalated projects.
Project failure in the information systems field is a costly problem and troubled projects are not uncommon. In many cases, whether a troubled project ultimately succeeds or fails depends on the effectiveness of managerial actions taken to turn around or redirect such projects. Before such actions can be taken, however, management must recognize problems and prepare to take appropriate corrective measures. While prior research has identified many factors that contribute to the escalation of commitment to failing courses of action, there has been little research on the factors contributing to the deescalation of commitment. Through deescalation, troubled projects may be successfully turned around or sensibly abandoned. This study seeks to clarify the factors that contribute to software project deescalation and to establish practical guidelines for identifying and managing troubled projects. Through interviews with forty-two IS auditors, the authors gathered both quantitative and qualitative data about the deescalation of commitment to troubled software projects. The interviews sought judgments about the importance of twelve specific factors derived from a review of the literature on deescalation. Interviews also generated qualitative data about specific actors and actions taken to turn troubled projects around. The results indicate that the escalation and deescalation phases of projects manifest different portraits. While there were no factors that always turned projects around, many actors triggered deescalation, and many specific actions accounted for deescalation. In the majority of cases, deescalation was triggered by actors such as senior managers, internal auditors, or external consultants. Deescalation was achieved both by managing existing resources better and by changing the level of resources committed to the project. We summarize the implications of these findings in a process model of project deescalation.
Information technology (IT) projects can fail for any number of reasons and in some cases can result in considerable financial losses for the organizations that undertake them. One pattern of failure that has been observed but seldom studied is the IT project that seems to take on a life of its own, continuing to absorb valuable resources without reaching its objective. A significant number of these projects will ultimately fail, potentially weakening a firm's competitive position while siphoning off resources that could be spent developing and implementing successful systems. The escalation literature provides a promising theoretical base for explaining this type of IT failure. Using a model of escalation based on the literature, a case study of IT project escalation is discussed and analyzed. The results suggest that escalation is promoted by a combination of project, psychological, social, and organizational factors. The managerial implications of these findings are discussed along with prescriptions for how to avoid the problem of escalation.
Information technology (IT) projects can fail for any number of reasons, and can result in considerable financial losses for the organizations that undertake them. One pattern of failure that has been observed but seldom studied is the runaway project that takes on a life of its own. Such projects exhibit characteristics that are consistent with the broader phenomenon known as escalating commitment to a failing course of action. Several theories have been offered to explain this phenomenon, including self-justification theory and the so-called sunk cost effect which can be explained by prospect theory. This paper discusses the results of a series of experiments designed to test whether the phenomenon of escalating commitment could be observed in an IT context. Multiple experiments conducted within and across cultures suggest that a high level of sunk cost may influence decision makers to escalate their commitment to an IT project. In addition to discussing this and other findings from an ongoing stream of research, the paper focuses on the challenges faced in carrying out the experiments.